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comprising a defined path of the tree for the user; and 
transmitting an identifier identifying one of the set of 
nodes to be used. 
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Description 

Field of the Invention 

[0001] The present invention relates to the allocation 
of code branches in the uplink and the downlink of CD- 
MA (code division multiple access) systems, and partic- 
ularly but not exclusively to UMTS (Universal Mobile Tel- 
ecommunication System). 

Background to the Invention 

[0002] In UMTS (Universal Mobile Telecommunica- 
tion System), the channelisation code dictates the band- 
width allocated toa particular service. In the uplink, each 
mobile station has its own channelisation code (or 
scrambling code) tree, since different uplink scrambling 
codes are allocated to different mobile stations. The 
code tree allocated to a particular mobile station will be 
shared among different radio access bearers (i.e. base 
stations) of that mobile station. However, with service 
multiplexing (multiplexing of transport channels), either 
a single channelisation code (for spreading factor less 
than 4) is used or multiple channelisation codes (also 
known as multicode, for high data rate) are used. The 
uplink channelisation code is allocated in a predefined 
order. The mobile and the network (i.e. the base station) 
only need to agree on the code number (which may be 
predefined) and spreading of the codes. The spreading 
factor is implicitly given in the transport format combina- 
tion indicator (TFCI) of the dedicated physical control 
channel (DPCCH). The exact codes to be used are thus 
implicitly given. Fast symbol rate change (at a resolution 
of 10 ms radio frame duration) is therefore possible on 
the uplink as long as the TFCI is decoded properly. No 
radio access bearer (RAB) modification is thus needed. 
However, due to the use of predefined channelisation 
code, the cross-correlation among mobile stations may 
degrade and thus increase the interference level. 
[0003] In the downlink, the channelisation code tree 
is shared among different mobile stations within a cell. 
This results in a downlink channelisation code shortage 
problem. A downlink channelisation code can only be 
allocated if and only if no other code on the path from 
the specific code to the root of the tree or in the sub-tree 
below the specific code is used within the same cell. This 
restriction on channelisation code allocation applies as 
well to the uplink except that it is for a mobile station and 
not for a cell. Moreover, the allocation of uplink chan- 
nelisation code can be easily predefined in such a way 
as to ensure that the restriction is not violated. As for 
the downlink, channelisation allocation can be quite 
complicated since it has to share the channelisation 
code tree among different mobile stations. A change in 
spreading factor in the downlink requires performing the 
RAB modification procedure. This is because the, 
DPCCH and the dedicated physical data channel (DP- 
DCH) are time-multiplexed and thus use the same chan- 



nelisation code. Decoding the TFCI in the DPCCH re- 
quires knowledge of the spreading factor in advance. 
Hence, a 10 ms symbol rate resolution change is not 
possible. A symbol rate change of 10 ms is still possible 

s through dynamic rate matching, however the spreading 
factor is constant (i.e. set to lower spreading factor than 
is required for the physical channel). 
[0004] The problem is summarised as follows. In the 
uplink, there is an increase in in interference level due 

to to the use of predefined channelisation code among mo- 
bile stations: 

[0005] In the downlink, there is a complicated code 
allocation algorithm to optimise the use of the channeli- 
sation code tree, a slow spreading factor changes due 

is to time-multiplexing of the DPCCH and DPDCH, and a 
code shortage problem due to a single code tree among 
different mobile stations within a cell. 
[0006] It is therefore an object of the present invention 
to provide a technique for communicating a channelisa- 

20 tion code allocation in the downlink of a spread spectrum 
CDMA system which results in an improved system per- 
formance. 

Summary of the Invention 

25 ^ 

[0007] According to the present invention there is pro- 
vided a method of communicating a selected channeli- 
sation code for a downlink to a user, comprising: trans- 
mitting a set of nodes of a code tree comprising a de- 

30 .fined path of the tree for the user; and transmitting an 
identifier identifying one of the set of nodes to be used. 
[0008] The set of nodes may be transmitted to the us- 
er during the radio access bearer establishment session 
between the user and a base station. The set of nodes 

35 may be included in the transport format set. 

[0009] The identifier may be transmitted in a data 
packet. The identifier may be transmitted in a transport 
format combination identifier. 

[0010] The invention will now be described by way of 
40 example with reference to the accompanying drawings, 
in which: 

Brief Description of the Drawings 

45 [0011] 

Figure 1 illustrates the basic principle of a code tree; 
Figure 2 is a flow diagram illustrating the general 
steps of a channelisation code allocation technique 

bo according to the prior art; 

Figure 3 illustrates a specific example of code allo- 
cation according to the technique of Figure 2; 
Figure 4 is a flow diagram illustrating the general 
steps of a new channelisation code allocation tech- 

55 nique; 

Figures 5(a) and 5(b) illustrate a specific example 
of code allocation according to the technique of Fig- 
ure 4; 
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Figure 6 illustrates the general steps in communi- 
cating a channelisation code for the downlink ac- 
cording to a known technique; and 
Figure 7 illustrates the general steps in communi- 
cating a channelisation code for the downlink ac- 
cording to a new technique. 

Description of Preferred Embodiment 

[0012] The new technique for allocating channelisa- 
tion codes described herein applies equally to channeli- 
sation code allocation in the uplink and the downlink. In 
the following description a general introduction to the 
concept of channelisation codes is given, followed by 
an overview of one current technique for allocating 
channelisation codes. Thereafter, the new technique of 
allocation of channelisation codes is described. 
[0013] The channelisation codes for UMTS for the up- 
link as well as for the downlink are orthogonal variable 
spreading factor (OVSF) codes which maintain orthog- 
onality between the different physical channels of one 
base station (downlink) or one mobile station (uplink), 
respectively. The OVSF codes can be described using 
the code tree of Figure 1 . 

[0014] The OVSF sequences are denoted by C xy 
(y=1 ,...,x;' x=2 k * 1 , k=1 ,...,9). Each level in the code tree 
defines channelisation codes corresponding to a 
spreading factor of SF=x. The code with 2y -i of the 
upper branch will be constructed by concatenation of 
two codes C x from the previous node. Thus for exam- 
ple, node C 4x4y „3 is the concatenation of the node 
c 2x.2y-i twice, which is in turn the concatenation of the 
node C xy twice. C 2x ^ from the lower branch is deter- 
mined by the concatenation of one code C x y and its neg- 
ative -C x y . Thus, for example, the node C 4x 4y is the con- 
catenation of C 2Xi2 y witn its negative, which in turn is the 
concatenation of the node C x y with its negative. The 
concatenation of nodes is illustrated in Figure 1. 
[0015] All codes within the code tree/as discussed 
hereinbelow, cannot be used simultaneously. In a 
known code allocation scheme (discussed in further de- 
tail hereinbelow), a code can be used for a physical 
channel if and only if no other code on the path from the 
specific code to the root of the tree or in the sub-tree 
below the specific code is used by another physical 
channel. 

[001 6] This concept is described in further detail here- 
inbelow, with reference to a specific example. 
[0017] The general steps to be taken in a -known 
scheme for allocating channelisation codes in a down- 
link are described below. It will be appreciated by one 
skilled in the art how this technique may be utilised in 
the uplink. 

[0018] In the down link the code tree is shared by all 
users, and a branch of the code tree is allocated for each 
user, each user having a unique channelisation code. 
This allocation effectively comprises two steps which 
are discussed in further detail hereinafter: defining an 
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origin node on the tree; and defining a path from the 
origin node on the tree. 

[0019] A channelisation code is typically allocated for 
a number of expected symbol rates, the symbol rate in 

s turn determining the spreading factor. That is, the down 
link channelisation code allocated to a particular user is 
. based on the fact that it is known the user will require a 
symbol rate within a particular range. Thus channelisa- 
tion codes within this range must be allocated. For allo- 

10 cation and de-allocation of radio resources, the highest 
symbol rate, i.e. the lowest spreading factor, first needs 
to be determined. This then gives the channelisation 

— code for the lowest spreading factor, and defines the or- 
igin node, or initial node, in the code tree. 

75 [0020] In this known technique, a node (and its sub- 
tree) can be assigned to one physical channel if and only 
if no other node on the path from the specific node to 
the root of the tree or in the sub-tree below the specific 
node is used by another physical channel from the same 

20 base station (downlink). Thus the code tree must be 
looked into in both directions from the initial node. 
[0021] From observation of the code tree of Figure 1 , 
this requirement can be defined by two rules as follows: 
[0022] 1 . If the origin node with code C x y (x=2 k ~ 1 , y<x) 

25 is used, all subsequent nodes (in the downward direc- 
tion) with code C vx ^y.-,^ (v=2 n , n>0 and u=1,...,v) are 
reserved or occupied and cannot be used by another 
physical channel. 

[0023] 2. From C x (x=2 k " 1 , y<x), in the upward direc- 
30 tion, al! codes with C vx [vy] , (v=2 n , n<0) are reserved or 
occupied and cannot be used by another physical chan- 
nel. The term [v.y] denotes the next highest integer 
number of (v.y). 

[0024] Rule 1 must be considered for allocation of se- 
35 quences with a spreading factor of interest of SF>x; Rule 
2 is for allocation of sequences with a spreading factor 
of interest of SF<x. 

[0025] The allocation of channelisation codes in the 
downlink according to a known technique will now be. 

40 described with reference the flow chart of Figure 2 and 
the specific example as illustrated by Figure 3 
[0026] In this example, it is assumed that there are 
three users. A first user requires a channelisation code 
with a spreading factor in the range of 4 to 8, a second 

45 user requires a channelisation code with a spreading 
factor in the range 4 to 8, and a third user requires a 
channelisation code with a spreading factor in the range 
" 2 to 8. 

[0027] In a first step 202, a code tree is allocated for 
50 the downlink, being the code tree generally shown in 
Figure 3. In a second step 204, the number of users is 
determined, and a parameter M set to be equal to the 
number of users. In the present example M is set equal 
to 3. At this stage a further parameter N is set to a value 

55 1, 

[0028] In a step 206 : ah origin node for the user N, i. 
e. the first user, is determined. The origin node for each 
user is determined based on the lowest required spread- 
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ing factor for each user. There are various techniques 
known for determining the origin node. In the present 
example it is assumed that the origin node is allocated 
based on the first node available in the tree. For the first 
user, the minimum required spreading factor is 4. Node 
C4,1 : designated by UtO in Figure 3, is allocated as the 
origin node for the first user. 

[0029] In a step 208, Rules 1 and 2 discussed here- 
inabove are applied for the first user (user N) based on 
the determined origin node. Thus, all nodes from node 
C4.1 in an upward and downward direction of the tree 
are reserved for the first user 1 . The reserved nodes are 
indicated by the nodes marked RU1 (and U1) in Figure 
3. 

[0030] In a next step 210 an origin node is defined for 
the second user (i.e. user N+1 ). The minimum required 
spreading factor 1or the second user is 4, and therefore 
an origin node with spreading factor 4 is selected. Node 
C4,1 is allocated as the origin node, being the first node 
with a spreading factor of 4. 

[0031] In a step 212 it is determined whether the allo- 
cated node for the second user clashes with the re- 
served branch based on the origin node for any previous 
user, in this case the only previous user being the first 
user. As the node C4,1 has been reserved by the first 
user- (and is in fact the first users origin node), the allo- 
cated node for the second user does clash. In a step 
216, the origin node for the second user is therefore re- 
defined. The next successive node with a spreading fac- 
tor of 4 is allocated tothe second user, and then checked 
for a clash in step 212 again. 

[0032] On this occasion there is no clash, and this 
node is therefore the origin node, designated U20, for 
the second user. The code allocation technique pro- 
ceeds to step 21 4. In step 214 Rules 1 and 2 are applied 
based on the origin node for the second user. All nodes 
in an upward and downward direction from node C4,2 
are reserved by user 2, as indicated by the designation 
of nodes marked_RU2 (and U2) in Figure 3. 
[0033] In a step 220, it is determined whether the cur- 
rent value N+1 is equal to M. At this point N+1 corre- 
sponds to 2, and therefore is not equal to M (3). In a step 
218 the value N+1 is incremented (to 3), and then the 
step 210 repeated for the third user The third user has 
a minimum spreading factor of 2. in step 210 the node 
C2,1 is defined as the origin node for the third user. In 
step 212 it is determined that this origin node clashes 
with the reserved branch for both the first and second 
users. In step 216 node C2,2 is allocated to the third 
user. In step 21 2 it is determined that this does not clash 
with any reserved branch ; and this mode is therefore the 
origin node, designated U30 f for the third user. Then in 
a step 214 all the upward and downward nodes from 
node C2,2 are reserved by the third user as designated 
by the nodes marked RU3 (and U3) in Figure 3. 
[0034] In step 220 it is determined that N+1 is equal 
to M, and the code allocation technique proceeds to step 
222. 



[0035] Having defined the origin nodes for all current 
users, the paths for all users must be defined. The 
lengths of the paths are determined by the required 
spreading factors to be supported. 

5 [0036] As discussed above, the codes of the upper 
branch are a straight concatenation of codes from the 
previous nodes, whereas the codes of the lower branch- 
es of the code tree are a concatenation of the codes 
from previous nodes with their negatives. From the the- 

10 oretical point of view both ways are assumed equivalent. 
However, from the implementation point of view the up- 
per branch is preferred. Using the lower branch at every 
change of the spreading factor the modulation se- 
quence ;:rtie channelisation code must be changed by 

is insertion or leaving out of the negative code. In contrast, 
using the upper branch the modulation sequence does 
not change during variation of the spreading factor, be- 
cause every code of the subsequent nodes consists of 
the concatenation of codes from the previous nodes. 

20 Therefore, by changing the spreading factor only the 
correlation period has to be changed but not the modu- 
lation sequence. Using the notation of the OVSF se- 
quences the rule of choosing the upper branch of the 
code tree starting from the node with the lowest SF can 

25 be written in the following way, and defined as Rule 3: 
[0037] 3. If the node with lowest SF mjn =x is given by 
C x y (x=2 k_1 ) use always the channelisation code of node 

C v .x. V .(y-1) + 1 Witn V=2n - ( SF actuaP v - x )- 

[0038] This rule implies that in the ideal case there 
30 may be no need to exchange the information about the 
whole code branch between mobile station and base 
station. Only the channelisation code for the lowest 
spreading factor and the actual used spreading factor 
must be known (in both the uplink and the downlink). 
35 [0039] In practice, however, some nodes cannot be 
choosen due to, for example, interference. These nodes 
may be marked as not preferred nodes. The following 
node C v .x. v of the lower branch should be chosen, 
instead. All subsequent nodes are taken by Rule 3 start- 
40 ing with node C v .x. v(y .-,y until a node in this path is 
marked as non preferred, too.- 

[0040] In step 222, the path for each user is defined. 
The first user requires a spreading factor of up to 8. It is 
assumed in Figure 3 that it is undesirable to use the 
45 node 08,1, and therefore the path is defined from C4.1 
to C8,2. The path defined for the first user is seen in 
Figure 3 from the origin node U10 to the node designat- 
ed U1. 

[0041] Similalry for the second and third users for the 
so respective required spreading factors discussed above 
the paths are defined. For the second user the path ex- 
" tends from the origin node designated by U20 to the 
nodes C8.3 and C16,5, each designated by U2. For the 
third user, the path extends from the origin node desig- 
ns nated by U30 to the nodes C4,3 and C8,5, each desig- 
nated by U3. 

[0042] In a step 224, a particular node of the defined 
path is then selected to be used by each user. This is 
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based upon the required spreading factor given the 
amount of data to be transmitted in the downlink asso- 
ciated with each user. For the purposes of the present 
example it is assumed that the first user has a required 
spreading lactor of 8, the second user has a required 
spreading factor of 1 6, and the third user has a required 
spreading factor of 8, 

[0043] In a step 226 communication then proceeds in 
the normal way. 

[0044] The new code allocation technique improves 
on the above-described technique, by enabling chan- 
nelisation codes to be re-used. Again, a specific exam- 
ple is given herein with reference to the downlink, but it 
will be readily understood how the technique extends to 
the uplink. Figure 4 is a flow diagram illustrating the gen- 
eral principles of the new technique, and Figure 5 rep- 
resents a specific example to illustrate the new tech- 
nique. 

[0045] In the new technique a code tree for use in the 
down link is allocated, as before, in a step 402. The al- 
located code tree is shown in Figures 5(a) and 5(b) and 
corresponds to the code tree of Figure 3. 
[0046] For the purposes of the present example ac- 
cording to the invention it is again considered that there 
are the same three users. In a step 404, corresponding 
to step 204, the parameter M is set to the number of 
users (3), and the parameter N is set to 1. 
[0047] In a step 406 origin nodes are allocated for 
each of the users. The origin nodes may be allocated to 
each user irrespective of the origin nodes allocated to 
other users. In the present example, as illustrated by 
Figure 5(a), node C4,1 is allocated as the origin node 
for both the first and second users, and node C2,2 is 
allocated as the origin node for the third user. 
[0048] It will be appreciated, however,, that the tech- 
nique for allocating the origin node may vary and will be 
implementation dependent. It will be understood that if 
there were three users each with a minimum spreading 
factor of 2, then one of the nodes C2.T and C2,2 would 
be allocated twice. In the prior technique described 
hereinabove, if there were three users each with a min- 
imum spreading factor of 2 then there would not be suf- 
ficient codes to allocate. Obviously, this concept ex- 
tends to more realistic examples. If there were seven- 
teen users each with a minimum spreading factor ol 1 6, 
then in the prior technique there would not be sufficient 
channelisation codes to allocate. In the present inven- 
tion, one of the nodes 016,1 ... C16.16- would be allo- 
cated twice. 

[0049] A method must generally be provided to ar- 
range the origin nodes associated with different chan- 
nelisation codes within the code tree, rather than the or- 
igin nodes being arbitrarily allocated. It is assumed that 
the RRA (radio resource allocation) algorithm has suc- 
cessfully checked the requested resources against the 
code space (i.e. the RRA algorithm has checked that 
there is sufficient code space to allocate resources to 
the users). Several methods for the arrangement of or- 
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igin nodes are possible. Two particularly advantageous 
practical solutions are described below. 

* [0050] In a first solution, at every run of the RRA al- 
gorithm, all physical channels are sorted according to 

5 , the necessary spreading factor. The sequences will be 
allocated in order of their spreading factor: e. g. at first 
the channels with highest spreading factor will be allo- 
cated to codes C x y with smallest x and y, then channels 
with next lower SF will be allocated to nodes C x y with 

io higher x and y etc. This procedure must be done itera- 
tively, because after every allocation of a node to a chan- 
nel an indication that subsequent and previous nodes 

— are not available must be done according to Rules 1 and 
2. This method of allocation / de-allocation of nodes is 

is simple, because all connections are handled equally as 
new connections. At every change of at least one chan- 
nelisation code a complete reshuffling of the code tree 
is done. 

[0051] In a second solution, the channelisation codes 
20 are allocated according to the time of arrival of Ihe RRC 
(radio resource control) connection requests. The allo- 
cation may be as follows. The first available code C x y 
with minimum x and y is given to the first incoming re-, 
quest, the next available code to the next request etc. 
25 Thus, code shuffling due to changes of a channelisation 
code is only done in the case that code branches starting 
with nodes of a higher spreading factor on different 
paths can be combined to avoid waste of code space 
(similar to de-fragmentation). Allocation and de-alloca- 
30 tion of the nodes must be done in consecutive steps, 
because the connections are now of three types: re- 
leased, changed and new ones. 

[0052] . In addition to the two above alternative meth- 
ods for allocating origin nodes, nodes with a bad inter- 
ns ference situation can be considered as not preferred. If 
there is enough code space available, then the code se- 
quence of such nodes should not be used. 
[0053] Once the origin nodes are allocated, then the 
paths for each user are defined in a step 408. In the 
40 illustrated example of Figure 5(a), for the first user a path 
from the origin node U10 extends through nodes C8.1 
and node C16.1, designated by numerals U1. For the 
second user a path extends from the origin node U20 to 
node C8.2 designated by U2. For the third user a path 
45 extends from the origin node U30, through nodes C4,3 
and C8, 5 designated by U3. 

[0054] Based on the amount of data to be transmitted 
in a particular communication, the spreading factor for 
the first user (user N) is then determined in a step 410. 

50 For the first user a required spreading factor of 8 is de- 
termined (as before) and node C 8,2 therefore selected 
for use in the downlink of the first user. In accordance 
with the new technique, in a step 412 the Rules 1 and 
2 are then applied in dependence on the selected node 

55 for the first user. Referring to Figure 5(b), the selected 
node for the first user is designated by SU1, and the 
nodes in the upward and downward direction therefrom 
reserved, as designated by RU.1 
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[0055] In a step 41 4, a node is selected for the second 
user (N+1 ) based on the determined spreading factor to 
be used. As before, the determined spreading factor is 
16, and node C 16,1 is therefore selected as designated 
by SU2 in Figure 5(b). 

[0056] In a step 41 6 it is checked whether the selected 
node forthe second user clashes with a branch reserved 
(according to Rules 1 and 2) for any previous user. In 
the present case, no clash takes place. 
[0057] If, however, the selected node did clash, then 
in a step 418 the origin node for the second (N+1 ) user 
is redefined, and in a step 420 the path for the second 
user redefined. The steps 414 and 416 are then repeat- 
ed. 

[0058] When it is determined that the selected node 
does not clash with a reserved branch for a previous 
selected node, in a step 422 the Rules 1 and 2 are ap- 
plied for the second user to reserve a branch in the up- 
ward and downward direction. For the second user, as 
shown in Figure 5(b), the selected node for the second 
user is designated SU2, and the nodes in the upward 
and downward direction therefrom reserved, as desig- 
nated by RU2. 

[0059] In a step 424 it is determined whether the value 
N+1 is equal to M. At this stage in the example the value 
N+1 is 2, and the technique proceeds to step 426, where 
the value of N+1 is incremented to 3 The node is se- 
lected for the third user in step 414 based on the re- 
quired spreading factor of 8 (as before). 
[0060] In step 416 it is determined that the selected 
node, designated by SU3 in Figure 5(b), does not clash 
with any reserved branch based on a selected node for 
another user. 

[0061] In step 422 Rules 1 and 2 are applied to re- 
serve the branch based on the selected node for the 
third user, and the upward and downward nodes re- 
served as designated by RU3 in Figure 5(b). 
[0062] In step 424 it is determined that N+1 is equal 
to M, and in a step 428 the communication is proceeded 
with. 

[0063] The new technique thus allows the crossing of 
the defined paths for different users based on all possi- 
ble channelisation codes for those users, which is pos- 
itively prevented in the known technique described 
hereinabove due to Rules 1 and 2 being applied based 
on the origin node. The new technique allows the re-use 
of channelisation codes which in turn mitigates the 
channelisation code shortage problem in the downlink. 
[0064] In an embodiment, the present invention may 
still be allocated in accordance with the application of 
Rules 1 and 2. That is channelisation codes may initially 
be allocated according to Rules 1 and 2. When a code 
shortage occurs, i.e. the number of users exceeds the 
available code space allowed by Rules 1 and 2, the re- 
use technique of the present invention may be utilised. 
[0065] The advantages of the new technique over the 
old technique described with reference to Figure 2 can 
be easily understood by a comparison of Figure 5(b) 



with Figure 3. These two Figures showthe allocated and 
reserved nodes of the code tree for the same users. As 
can be seen in Figure3, once the channelisation codes 
for the three users have been allocated, the code tree 
5 is full and there are no more available codes for use. 
Conversely, referring to Figure 5(b), it is seen that based 
on the same three users a large amount of the code tree 
is still available for use. 

[0066] Referring also to Figure 5(b), it can be seen 
10 that if the spreading factor for a particular user changes, 
then it may be necessary to redefine the code tree. For 
example, if the spreading factor for the first user 
— changed to 4, then the node for the first user with a 
spreading factor of 4 (C4,1) would clash with a node re- 
is served by the second user. If it is necessary that both 
users are supported at the same time, then it will be nec- 
essary to redefine the code tree. One way of efficiently 
dealing with this would be to allocate two defined paths 
to the first user in the beginning. Thus rather than merely 
20 moving along a defined path in response to a changing 
spreading factor, it is possible to move between defined 
paths. 

[0067] It is also possible that when a clash is caused 
by the adaptation of the spreading lactor for a particular 
25 user, that one ol the. two users which clash may have 
priority over the other. In this case one user may be 
stopped from operating whilst the other proceeds. 
[0068] It is also possible that any two users may in 
any event not be operating at the same time Thus even 
30 if a clash exists between a selected node and a reserved 
node there may be no detriment to performance if the 
two users do not operate at the same time. 
[0069] A technique for configuring the downlink con- 
nection between a base station and several users (mo- 
ss bile stations) according to the prior art will now be de- 
scribed. Figure 6 illustrates the general steps of the prior 
art technique. If the downlink communication is initiated 
by a user, then in a step 602 a radio resource allocation 
establishment takes place. This consists of a user send- 
ee ing a radio resource allocation request to the base sta- 
tion, and the base station sending a radio resource al- 
location grant signal back to the user. 
[0070] In a step 604 a radio resource control (RRC) 
connection establishment takes place. The RRC estab- 
45 lishment establishes a signalling link between the user 
and the base station for exchanging control information. 
For example, the user may provide the base station with 
control information concerning the quality of service re- 
quired for the communication session, such as the type 
so of data. The RRC connection establishment will be fa- 
miliar to one skilled in the art. - 

[0071] In a step 606 a radio access bearer (RAB) set- 
up procedure is initiated to establish the physical chan- 
nel for user data. Again, the RAB establishment of steps 
ss 606 to 612 will be familiar to one skilled in the art and 
only sufficient description is given herein to enable un- 
derstanding of the how the new technique for commu- 
nicating channelisation codes in the downlink, dis- 
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cussed further hereinbelow, operates. 
[0072] In a step 608 the code for the user to use is 
determined, in accordance with the techniques of either 
Figure 2 or 4, and then in a step 610 the selected node 
only of the code path allocated to the user is communi- 
cated to the user. Thus at this stage, the required 
spreading factor for the communication session is de- 
termined such that only the one of the nodes of the de- 
fined branch which is required for the current communi- 
cation session is selected and communicated to the us- 
er. 

[0073] In a step 61 2 the RAB procedure is completed, 
and then in a step 614 the downlink communication be- 
tween the user and the mobile station proceeds based 
on the established RAB. 

[0074] In a step 61 6, a change in the spreading factor 
for the particular user is required due, for example, to a 
change in the volume of data to be transmitted. In a step 
618 a RAB request is initiated, and then in step 620 a 
RAB is performed, and a new selected node of the 
branch communicated to the user. In a step 622 the RAB 
is completed, and then in a step 624 communication 
continues based on the newly established RAB. ' 
[0075] Thus once communication is established, eve- 
ry time there is a change required in the spreading factor • 
of the channelisation code, due for example to a change 
in the bandwidth, then a new RAB establishment must 
take place. 

[0076] The new advantageous technique for estab- 
lishing the downlink is now described with reference to 
Figure 7. As before, if the downlink communication is 
initiated by a user, then in a step 702 a radio resource 
allocation establishment takes place. This consists of a 
user sending a radio resource allocation request to the 
base station, and the base station sending a radio re- 
source allocation grant signal back to the user. In a step 
704 a radio resource control (RRC) establishment takes 
place. In a step 706 a radio access bearer (RAB) set-up 
procedure is initiated to establish the physical channel. 
[0077] Ina step 708 a channelisation code is allocated 
to the user, preferably in accordance with the technique 
of Figure 4. 

[0078] In a step 710, the branch defined for the par- 
ticular user is communicated to the user. That is, all pos- 
sible nodes of the defined path are communicated to the 
user. 

[0079] The allocated code path, i.e. the defined path, 
is communicated to the user during RAB establishment 
when the Transport Format (TF) and the Transport For- 
mat Combination Set (TFCS) is transmitted to the user 
via the RRC connection. The transport format consists 
of a dynamic part and a semi-static parts .'The dynamic 
part is modified to include downlink channelisation code 
labels <x d , y d such that C xd yd ). 

[0080] Thus, referring to the example of Figures 5(a). 
and 5(b) hereinabove, for user 1 the downlink channeli- 
sation code labels [4,1 ; 8,2] would be sent, defining the 
path shown by U10 through U1 in Figure 5(a). For user 



2 the downlink channelisation code labels [4,1; 8,1; 
16,1] would be sent, defining the path shown by U20 
through U2 in Figure 5(a). For user 3 the downlink chan- 
nelisation code labels [2,2; 4,3; 8,5] would be sent, de- 

5 fining the path shown by U30 through U3 in Figure 5(a). 
[0081] The semi-static part remains as before. The 
purpose of adding the labels of the downlink channeli- 
sation codes is to accommodate fast changing of the 
spreading factor and its corresponding channelisation 

10 code. 

[0082] Then in a step 712 the RAB establishment is 
complete. 

~ [0083] In a step 714, a communication based on the 
established RAB takes place. The data packets sent 
during the communication .each include a transport for- 
mat communication indicator (TFCI), and according to 
the new technique the TFCI is modified to include an 
identifier identifying the one of the set of nodes sent to 
the user in the TFS during RAB establishment to be se- 

20 lected for use in the downlink. Thus, again referring back 
to the example of 

[0084] Figures 5(a) and 5(b), for user 1 the TFCI will 
identify the second of the channelisation code labels 
sent during the RAB establishment. 

25 [0085] In a step 71 6, a change in the spreading factor 
is required. In a step 718 the label in the TFCI of the 
data packets is therefore modified with the node of the 
branch for the new spreading factor, then in a step 720 
the communication continues based on the originally es- 

30 tablished RAB. 

[0086] Thus it can be seen that by communicating all 
possible nodes of the defined path for a user to the user 
during the RAB establishment, there is no requirement 
for the RAB establishment to be repeated each time 

35 there is a need to change the spreading factor, as is the 
case in the prior art. 



Claims 

40 

1. A method of communicating a selected channelisa- 
tion code fora downlink to a user, comprising: trans- 

. mitting a set of nodes of a code tree comprising a 
defined path of the tree for the user; and transmit- 
45 ting an identifier identifying one of the set of nodes 
to be used. 

2. The method of claim 1 wherein the set of nodes are 
transmitted to the user during the radio access 

so bearer establishment session between the user and 
a base station. 

3. The method of claim 2 wherein the set of nodes are 
included in the transport format set. 

.55 

4. The method of claim 1 or claim 2 wherein the iden- 
tifier is transmitted in a data packet. 
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The method of claim 4 wherein the identifier is trans- 
mitted in a transport format combination identifier. 
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